Chapter 6
The Cost of Complexity
"Complexity rarely originates from individual systems. It emerges from the relationships between them."
Why This Chapter Exists
Complexity is often misunderstood.
Developers frequently associate complexity with the size of a class.
A class grows.
More functions are added.
Additional members appear.
Eventually, the class becomes difficult to understand.
While this certainly contributes to complexity, it is rarely its true source.
The greatest architectural challenges rarely exist inside a subsystem.
They exist between subsystems.
Understanding this distinction fundamentally changes how software is designed.
Complexity Is Not the Enemy
The Cube Framework does not attempt to eliminate complexity.
That would be impossible.
Every meaningful software project eventually becomes complex.
Networking introduces complexity.
Gameplay introduces complexity.
Animation introduces complexity.
Large content libraries introduce complexity.
The objective is therefore not to remove complexity.
The objective is to organize it.
Hidden Complexity
Some architectures appear simple.
A single manager controls everything.
Every subsystem communicates directly.
Objects freely modify one another.
Initially, this feels convenient.
There are fewer classes.
Fewer files.
Less navigation.
Unfortunately, complexity has not disappeared.
It has merely become invisible.
Dependencies grow unnoticed.
Responsibilities overlap.
Changing one system unexpectedly affects another.
The architecture slowly becomes unpredictable.
Visible Complexity
The Cube Framework intentionally chooses a different approach.
Responsibilities remain explicit.
Subsystems remain small.
Relationships are clearly defined.
At first glance, this may appear more complicated.
There are more moving parts.
More boundaries.
More interactions.
Paradoxically, this often makes the architecture easier to understand.
The complexity already existed.
The framework simply refuses to hide it.
Managing Relationships
Every relationship between two systems creates architectural cost.
Dependencies require maintenance.
Communication requires understanding.
Ownership requires clear boundaries.
The goal is therefore not to minimize the number of systems.
The goal is to minimize unnecessary relationships.
Healthy architectures contain many independent systems connected by few well-defined interactions.
Simplicity Through Isolation
Isolation is one of the most effective tools for managing complexity.
When a subsystem performs one responsibility well, other systems require little knowledge about its internal implementation.
They simply trust its public behavior.
This reduces coupling.
It also allows implementations to evolve independently.
Small isolated systems create architectures that remain approachable long after the project has grown.
Complexity Is Paid Eventually
Architectural decisions always have a cost.
Ignoring complexity today does not eliminate it.
It postpones it.
Sooner or later, every project must decide where that cost will be paid.
The Cube Framework chooses to invest early.
Responsibilities are clarified before features accumulate.
Boundaries are established before systems become dependent on one another.
This investment reduces the long-term cost of change.
Design Note
Whenever a subsystem becomes difficult to understand, avoid asking:
"Should this class be split?"
Instead ask:
"Which relationships have become unclear?"
The answer often reveals the true source of the complexity.
Framework Law VI
Complexity grows through relationships. Architecture exists to make those relationships understandable.
Healthy software is not defined by the absence of complexity.
It is defined by the clarity with which complexity is organized.
Looking Ahead
In the next chapter, we will explore why architecture depends not only on structure, but also on language.
Before developers can share responsibilities, they must first share vocabulary.
Revision History
Version 1.0
Initial publication.